In a system using hybrid ARQ (Automatic Repeat Request), data are coded and transmitted to the receiver. The receiver tries to decode the data and, if errors are found in the received data, the receiver requests a retransmission of the data unit by transmitting a negative acknowledgement (NACK) signal to the transmitter. If no errors are found in the decoding process, the received data unit is considered to be correctly received and the receiver transmits an acknowledgement (ACK) signal to the transmitter. The performance of the hybrid ARQ (HARQ) mechanism can be further enhanced by performing soft combining, i.e., the receiver buffers the erroneously received data unit and combines the buffered soft information with the soft information received due to the retransmission(s). By using several HARQ retransmissions the effective data rate is reduced and the data can be transmitted at the cell border but with an increased delay.
In HSDPA systems, the user data is carried over HS-DSCH (High Speed-Downlink Shared Channel) while the control information including the transport format and also the HARQ information, e.g. HARQ process number and a new data indicator, is carried over HS-SCCH (High Speed-Shared Control Channel). Each HARQ entity is capable of supporting multiple (up to 8) stop-and-wait HARQ processes. The motivation behind this is to allow for continuous transmission to a single UE, which cannot be achieved by a single stop-and-wait scheme. Configuring the number of HARQ processes is done by the network through higher-layer signaling. The transport format selection for user data transmission is usually based on the received CQI (Channel Quality Indicator) and available HS power, to meet a certain received quality requirement (e.g. 10% BLER). However, in some cases, due to a bad radio condition (e.g., in deep fading or at the cell border), or due to not enough resources available (e.g., channelization codes or HS power), any transport format even the smallest transport block size (e.g. 365 bits), can not be selected. In a multi-user scheduling environment, this results in that some users at the cell border maybe have no chances to be scheduled due to a very low achievable received quality, even using a round-robin scheduler, which is a relatively fair scheduler in the resource sharing sense. Not selecting any transport block becomes an issue in such cases, in particular for some delay sensitive services that normally have tight delay requirements.
One solution can be to loose the received quality requirement in the Node B for the smallest transport format (e.g. 365 bits). For instance, changing the minimum received quality requirement in terms of HS-DSCH Signal-to-Noise Ratio (SNR) to a relatively low value might result in data transmission anyway, although the consequence could be to have some retransmissions because relatively low received quality will have a higher block error probability than the desired 10% level. Of course, this solution could be better than transmitting nothing from the delay perspective.
One problem in the above solution of loosing the received quality requirement is that the delay for the selected smallest transport format could be still relatively long, compared to the required delay for those delay sensitive services. The reason is that Node B has to wait for the feedback reported from the UE after the first transmission. However, the feedback could be most likely a NACK as the received quality doesn't meet the desired requirement (10% BLER).